Current docker with the fix which i'm using now for the Nest Doorbell 2:
misecichin/go2rtc-nest:1.9.10-nestfix

Independent confirmation, from a different deployment and a different consumer path: this is real, and your diagnosis matches mine exactly.

I hit the same thing on a Nest Doorbell (wired) via nest: on go2rtc 1.9.14, with an RTSP consumer rather than Frigate. Same mechanism — Conn.GetTrack dedupes by *Codec pointer, Nest starts transmitting on a payload type that resolves to a different *Codec, the lookup misses, and a second unwired Receiver is created while every already-attached consumer starves. /api/streams shows two video receivers, one with childs and no bytes, one with bytes and no children.

What made it maddening to diagnose is that it is dial-order dependent: a cold dial mis-binds essentially every time, while a consumer attaching to an already-warm producer binds correctly. So it presents as "recording works if I open the camera first," which sends you looking in entirely the wrong place.

I filed it as #2389 before finding this PR — happy for that to be closed as a duplicate if you'd rather consolidate. #2386 is a third independent report (Nest Doorbell Gen 2 via Frigate, also stuck in a restart loop), and #2365 is arguably a fourth party hitting a downstream symptom of the same starvation. Cross-linking them here so it is clear this is not a one-off.

One suggestion on the patch itself

The lookup matches on Media alone:

for _, track := range c.Receivers {
    if track.Media == media {
        return track, nil
    }
}

core.Media.Codecs is a list, and getMediaCodec (pkg/webrtc/conn.go) selects among those codecs by the transmitted payload type. So "same Media" does not imply "compatible codec" — a video m-line that offered H264 and VP8 is ordinary WebRTC, and a remote moving from the H264 PT to the VP8 PT would, with this patch, be handed the receiver still described as H264. Consumers would then get VP8 RTP labelled H264, which fails in a much more confusing way than the bug being fixed.

Adding the compatibility check costs nothing and bounds it to the case you actually observed:

for _, track := range c.Receivers {
    if track.Media == media && track.Codec.Match(codec) {
        return track, nil
    }
}

Codec.Match compares name, clock rate and channels (and ignores FmtpLine), so a genuine PT-switch-within-the-same-codec still matches — which is the Nest behaviour — while a switch to a different codec falls through to the existing create path rather than being silently mis-wired.

The variant I have been running in production

For what it is worth, mine updates the receiver's codec rather than returning it as-is, and is gated to the Nest source to bound the blast radius:

if c.FormatName == "nest/webrtc" {
    for _, recv := range c.Receivers {
        if recv.Media == media && recv.Codec != codec && recv.Codec.Match(codec) {
            recv.Codec = codec
            break
        }
    }
}
track, err := c.GetTrack(media, codec)

Updating recv.Codec keeps the receiver's description in step with what is actually arriving, which matters for anything reading the codec downstream (the RTSP server copies FmtpLine into DESCRIBE). Your version is simpler and covers more sources, which I think is the better shape for upstream — I mention mine only because the two differ in that one respect and it may be worth a deliberate choice rather than an accident.

Running since 2026-07-31 across four Nest cameras: cold restarts now produce one video receiver with bytes flowing, zero starved receivers, and the "recording delivered audio but no video" failures are gone.